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SPECIFICATION 



To all whom it may concern: 

Be It Known, That I, Scott Hartop, of London, United Kingdom, have invented 
certain new and useful improvements in STREAMING OF DATA, of which I declare 
the following to be a full, clear and exact description: 
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STREAMING OF DATA 

Background of the Invention 

This invention relates to streaming of data, and more generally to the distribution of 
rich media and data on-line and over any network, notably the Internet. 

Streaming technology is a major growth area in the Internet field. It helps to satisfy 
public demand for large multimedia files by allowing parts of such a file to be displayed, 
played or otherwise accessed and used while other parts of the file are still downloading. In 
this way, streaming helps users whose terminals have insufficient access speed, memory and 
processing capabilities for them to be able to download complete multimedia files quickly 
enough to enjoy their use. 

Examples of streaming formats are RealVideo and RealAudio developed by 
RealNetworks, Inc. (all trade marks acknowledged). With suitable plug-ins on their browser 
programs, users with even modestly-specified terminals and modems can enjoy streamed 
data such as a live audio/video feed from a concert. 

Streaming relies upon the client terminal collecting data and sending that data as a 
steady stream to an application that processes the data, for example by converting that data to 
sound and/or pictures. Despite the use of a buffer to store an excess of incoming data and 
hence to insulate the application from interruptions in the incoming data stream, it often 
happens that the data does not arrive quickly enough to replenish the buffer. For example, 
network congestion can arise due to the essentially client/server architecture of the Internet. 
The result is a lack of smoothness in the data stream presented to the application and 
consequential loss in the quality of the user's experience, manifested by interruptions and 
other degradation. 

Even if the data stream is smooth enough to allow continuity, the quality of the data, 
for example in terms of image resolution and image size, is often poor. Put simply, the 
quality of the data equates to the rate at which information is transmitted, in terms of the 
amount of data transmitted in a given time, and this rate is compromised in an effort to ease 



downloading, to make it easier to keep the buffer replenished, and to minimize interruptions 
in the data stream. 

In today's predominantly client/server Internet architecture, high concurrency rates 
place bandwidth-intensive demands on servers dedicated to the streaming of continuous data. 
This drastically compromises the quality and reliability of the end-user's experience. It also 
results in high hardware overheads for streaming service providers, who need to maintain 
banks of specialized servers. 

Summary of the Invention 

Against this background, the invention resides in a method of optimizing data 
streaming in a peer-to-peer architecture comprising a plurality of clients in a chain, the 
method comprising each client monitoring its own bandwidth, informing a succeeding client 
in the chain of that bandwidth, comparing its own bandwidth with the bandwidth of a 
preceding client in the chain and, in response to a difference between the compared 
bandwidths, reordering its position among the clients in the chain. 

Similarly, the invention can be expressed in terms of a peer-to-peer data streaming 
system comprising a plurality of clients in a chain, each client including bandwidth- 
monitoring means for monitoring its own bandwidth, communication means for informing a 
succeeding client in the chain of that bandwidth, comparison means for comparing its own 
bandwidth with the bandwidth of a preceding client in the chain, and reconfiguration means 
responsive to a difference between the compared bandwidths to reorder its position among 
the clients in the chain. 

From the client perspective, the invention resides in a client terminal for use in a peer- 
to-peer data streaming system that comprises a plurality of client terminals in a chain, the 
client terminal being configured or programmed to include bandwidth-monitoring means for 
monitoring its own bandwidth, communication means for informing a succeeding client 
terminal in the chain of that bandwidth, comparison means for comparing its own bandwidth 
with the bandwidth of a preceding client terminal in the chain, and reconfiguration means 



3 



responsive to a difference between the compared bandwidths to reorder its position among 
the client terminals in the chain. 

The client terminal can of course be a client computer such as a home or office PC 
but can take other forms such as, without limitation, a set-top box, a games console, a 
5 networked hi-fi system or other network device. 

The invention therefore enables and provides a streaming architecture which uses a 
piece of software to link any networked computing device (referred to herein as clients or 
peers) in a continuous, dynamically self-organizing peer-to-peer chain for the purpose of 
streaming any kind of data more efficiently and with higher, more reliable throughput. That 
j!l 1 0 software is optionally downloadable or may be distributed in any convenient format. The 
O invention also includes a client/server coordinating element to originate and monitor the 
Cj chain, capable of handling appropriate content management and permissions functions. 
:E This invention transfers streaming from the known client/server architecture to a 

ill 

£ peer-to-peer architecture, exponentially reducing the processing power necessary to stream 

\± 1 5 any continuous data and enabling far higher quality (i.e. a higher rate of information transfer, 

5^ with less interruptions) to be achieved within the existing internet infrastructure. 
IH This invention also solves the potential 'bottle-neck' effect within the cascaded 

Zl streaming path by dynamically self-organizing the participating terminals or networked 

T:' r "" 

devices into the most efficient configuration at any given moment, without interrupting the 

20 streamed information. 

In the system or terminal of the invention, a client or client terminal preferably 
includes address-providing means for receiving and storing the address of a preceding or 
succeeding client or client terminal in the chain and providing that address to, respectively, 
the succeeding or preceding client or client terminal in the chain. Thus, for example, each 

25 client can identify a preceding client in the chain to the succeeding client in the chain. 

Similarly, the detecting client can identify a succeeding client in the chain to the preceding 
client in the chain. 

If a detecting client detects that its bandwidth is greater than that of the preceding 
client in the chain then, in response, it opens a connection with a client upstream of the 



preceding client. In parallel, the preceding client in the chain can open a connection with the 
identified succeeding client. 

In apparatus terms, the comparison means of a client or client terminal is associated 
with connection means for receiving the address of, and opening a connection with, a client 
or client terminal upstream of the preceding client or client terminal if the comparison means 
detects that the bandwidth of its associated client or client terminal is greater than that of the 
preceding client or client terminal in the chain. 

The or each of the new connections is preferably opened concurrently with pre- 
existing connections between clients in the chain. Once the or each concurrent connection 
has been made to a client, the or each associated pre-existing connection to that client can be 
dropped. In that event, the client advantageously switches to reading local buffer memory 
before the pre-existing connection is dropped. 

In the reordered chain, therefore, the detecting client can receive streamed data from 
the client upstream of the preceding client and can forward that streamed data to the 
preceding client. For example, the pre-existing connection between the preceding client and 
the detecting client can be reversed, or a replacement connection can be opened between the 
preceding client and the detecting client. Similarly, in the reordered chain, the succeeding 
client can receive streamed data from the preceding client. 

Once the chain has been reordered, a client preferably synchronizes a timecode of 
data in local buffer memory with a timecode of data received from a new streamed data input 
source before switching to data received from that source. The client can then replenish its 
local buffer memory. 

The invention extends to an optionally-downloadable software application that is 
adapted to configure or program a client terminal to implement the inventive features 
expressed above. 

Brief Description of the Drawings 

In order that this invention may be more readily understood, reference will now be 
made, by way of example, to the accompanying drawings in which: 
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Figure 1 is a diagram of a first step in the process of the invention, in which 
communication is established between a new client and a coordinating server; 

Figure 2 is a diagram of a second step in the process of the invention, in which 
communication is established between the new client and another client from which the new 
5 client receives streamed data and forwards that data to other clients along a peer-to-peer 
chain; 

Figure 3 is a diagram of a third step in the process of the invention, in which a further 
client joins the chain of Figure 2 and concurrent connections are made between clients in 
preparation for re-routing data flow among the clients in the chain; and 
Ji: 1 0 Figure 4 is a diagram of a fourth step in the process of the invention, in which data 

0 flow has been re-routed among the clients in the chain. 

H 

;|? Detailed Description 

5 si 

,13 A consumer interested in receiving any streamed data (for example, a live 

!\ 15 audio/video feed from a concert) first of all subscribes to the service. Having been granted 

W membership, that consumer is able to download or otherwise obtain a software application to 

1 jj the networked device or terminal that the consumer intends to use to interpret or decode the 
H streamed information. This application could be branded, can be customizable (for example 

by means of 'skins' that impose various attributes of appearance) and may feature additional 
20 functionality, but its core jobs are as follows: 

1 . Communicating briefly with a coordinating server to be allocated a starting 
place in a peer-to-peer chain of networked devices. 

2. Having dropped this server connection, establishing a connection to the IP 
address allocated by the server, from which address the desired streaming signal can be 

25 received. 

3 . Providing 'repeater' functionality such that the application can pass on the 
encoded signal to a succeeding terminal or networked device in the chain (being the 
subsequent node in the peer-to-peer connection) without interrupting the signal, and also 
simultaneously decoding the incoming signal and relaying this to the appropriate playback 
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device or application associated with the user's networked device. Of course, depending on 
the playback device or application, interpreting the codec may not be necessary. 

4. As background functions: 

(a) obtaining bandwidth information by monitoring the connection speed 
of the host networked device or terminal, for example by averaging over a period of time a 
series of regular and frequent counts of the rate at which data is received (suitably measured 
in bits per second, say every 500 milliseconds); 

(b) providing a continuous (or frequently enough to be effectively 
continuous) update of this bandwidth information to the succeeding networked device or 
terminal in the chain, together with the IP address of the preceding networked device or 
terminal in the chain for use when adjusting the client streaming order, as will be described; 
and 

(c) comparing its own throughput rate with that of the preceding 
networked device or terminal in the chain. 

5. As a result of learning that its host networked device or terminal is operating 
faster than the preceding networked device or terminal in the chain from which data is 
currently being received, the application manages the process of creating a new connection 
with the next preceding networked device or terminal, one link further up the chain. This 
involves the application seamlessly adjusting the position of its associated networked device 
in the chain or streaming cascade without disturbing the relative position of the streamed 
information, and then terminating the previous 'bottle-necking 1 connection. 

6. Log the streaming activity of the machine for corroboration with the 
coordinating server at an appropriate future time. 

Referring firstly then to Figure 1 of the drawings, a new client C contacts a 
coordinating server S in normal client/server architecture. The server S processes the request 
according to subscription/membership details uploaded from the client C and once access is 
confirmed, passes to the client C a decryption key for the requested stream and the IP address 
of the last client that the server S processed and added to a chain. 
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Figure 2 shows the next step in the process, in which the new client, which will 
henceforth be called Client 5, drops the connection to the server and switches to the allocated 
client identified by the server (this being Client 4, formerly the last in the chain). Client 5 
then begins to receive streamed data from Client 4. That data is time-coded frame-by-frame. 
5 In Figure 3, another client, namely Client 6, has joined the chain of Figure 2. The 

above-mentioned bandwidth monitoring function run by Client 5 and taking bandwidth 
information from Client 4 detects that Client 5 is faster than Client 4, Client 4 thus presenting 
a potential bottleneck in comparison with Client 5. To avoid this, Client 5 briefly sends the 
IP address of Client 6 to Client 4, whereupon Client 4 forges a concurrent connection with 
10 Client 6. Meanwhile, Client 5 forges a concurrent connection with Client 3, whose IP 
address is already known to Client 5 because Client 4 included that IP address with the 
bandwidth information it sent to Client 5. That done, and in preparation for the steps shown 
in Figure 4, Clients 4, 5 and 6 all switch to reading their local buffer memory of the streamed 
signal to preserve continuity in their output to their users. 
!\. 1 5 In Figure 4, having adjusted buffer times and synchronized timecode where necessary 

[U to ensure a contiguous stream: 

I ]S Client 5 switches to receiving and processing the signal from Client 3 and reverses 

the direction of its connection to Client 4. In other words, Client 5 sends its cascaded output 
to the IP address of Client 4 (a new replacement connection may need to be established here 
20 to achieve this); 

Client 4 switches to receiving and processing the streamed signal from Client 5 and 
outputting to Client 6; and the concurrent (but now unused) connections between Clients 3 
and 4 and Clients 5 and 6 are dropped. 

Using the timecode of the current frame being played from buffer memory to 
25 synchronize with the timecode of the new streamed input source, all clients revert to 
processing the streamed information and replenish their local buffers as quickly as 
connection speed allows. 
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It will be apparent from the foregoing that the chain has optimized itself according to 
local rules, without server coordination. Changes in available bandwidth at any point in the 
chain are dynamically resolved as they occur. 

The last client in the chain can never be replaced via this self-organizing process in 
order that the coordinating server handling requests to join the chain knows the IP address 
that defines where to instruct newcomers to connect, bearing in mind that the server is not 
connected to a client in the chain while the chain reconfigures itself during self-optimization. 

By means of the invention, a domestic user or consumer can, for example, launch the 
software, join a peer-to-peer chain streaming a piece of live theatre which is already in 
progress and automatically enjoy optimum network performance, regardless of the physical 
ceiling of the connection, whilst monitoring the show on their preferred home entertainment 
device such as a PC, a home cinema system and so on. The user may already have 
subscribed to and paid for this content, or could be billed on quitting the chain based on the 
amount of content actually streamed by their terminal. 



